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Abstract 

Haskell, as implemented in the Glasgow Haskell Compiler (GHC), 
is enriched with many extensions that support type-level program- 
ming, such as promoted datatypes, kind polymorphism, and type 
families. Yet, the expressiveness of the type-level language remains 
limited. It is missing many features present at the term level, includ- 
ing case expressions, anonymous functions, partially-applied func- 
tions, and let expressions. In this paper, we present an algorithm - 
with a proof of correctness - to encode these term-level constructs 
at the type level. Our approach is automated and capable of pro- 
moting a wide array of functions to type families. We also highlight 
and discuss those term-level features that are not promotable. In so 
doing, we offer a critique on GHC's existing type system, show- 
ing what it is already capable of and where it may want improve- 
ment. We believe that delineating the mismatch between GHC's 
term level and its type level is a key step toward supporting depen- 
dently typed programming. 

We have implemented our approach as part of the singletons 
package, available online. 

Categories and Subject Descriptors F.3.3 [Logics And Meanings 
Of Programs]: Studies of Program Constructs - Type structure; 
D.3.1 [Programming Languages]: Formal Definitions and Theory 
- Semantics; D.3.2 [Programming Languages]: Language Classi- 
fications - Haskell 

Keywords Haskell; type-level programming; defunctionalization 

1. Introduction 

Haskell, especially as implemented in the Glasgow Haskell Com- 
piler (GHC), is endowed with a plethora of facilities for type- 
level programming. Haskell 98 on its own has type classes (Wadler 
and Blott 1989), parametric polymorphism, and inferred higher- 
order kinds. Over the past 15 years or so, more and more features 
have been added, such as functional dependencies (Jones 2000), 
first-class polymorphism (Peyton Jones et al. 2007), generalized 
algebraic datatypes (GADTs) (Cheney and Hinze 2003; Peyton 
Jones et al. 2006), type families (Chakravarty et al. 2005a,b; Ei- 
senberg et al. 2014), and datatype promotion with kind polymor- 
phism (Yorgey et al. 2012). 

Now, we might ask: Are we there yet? 
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In other words, is type-level programming expressive enough? 
To begin to answer this question, we must define "enough." In this 
paper, we choose to interpret "enough" as meaning that type-level 
programming is at least as expressive as term-level programming. 
We wish to be able to take any pure term-level program and write 
an equivalent type-level one. 

Our answer to this question: "Almost." As we describe in more 
detail in Section 4, Haskell's type system as it appears in GHC 7.8 
is capable of expressing almost all term-level constructs, includ- 
ing anonymous functions, partially applied functions, case and let 
expressions, and even type classes. However, a few key pieces are 
missing. As described by Yorgey et al. (2012) and expanded on by 
Weirich et al. (2013), GADTs cannot be promoted. Haskell also 
lacks higher-order sorts, which would classify the promotion of 
higher-kinded type variables, including the m in Monad m. There 
are other limitations, as well; see Section 5. 

Despite these limitations, we have found that a wide array of 
programs are indeed promotable, using a mechanical translation 
implemented in Template Haskell (Sheard and Peyton Jones 2002). 
Our implementation is based on work started by Eisenberg and 
Weirich (2012) and is part of the singletons package. 1 

Why might we want to promote all these term-level constructs? 
As Haskell inches ever closer to being dependently typed (Weirich 
et al. 2013; Gundry 2013; Lindley and McBride 2013), it will 
become important to identify precisely which term-level constructs 
are available to be used in dependent contexts - that is, which 
terms really can be used in types? The present work defines this 
subset concretely and helps to set the stage for a dependently-typed 
version of Haskell. 

We make the following contributions: 

• We describe an enhancement to the singletons library, which 
promotes term-level definitions to the type level. We focus 
only on promoting expressions and declarations as defined in 
chapters 3 and 4 of the Haskell 2010 Language Report (Mar- 
low 2010). Our implementation relies on many extensions of 
GHC 7.8 but without the need to add new features. (Section 4) 

• We delimit exactly what features are not promotable under our 
implementation, and why these would be impossible to promote 
without further enhancements to Haskell. (Section 5) 

• Section 6 describes a formalization of Haskell and presents a 
proof, given in full in the extended version of this paper (Eisen- 
berg and Stolarek 2014), that our promotion algorithm produces 
well-kinded types. We also show that, if we assume the cor- 
rectness of our implementation of lambda-lifting, a promoted 
expression reduces in the same way as the original expression. 

• We conclude in Sections 7 and 7.5 with reflections on GHC's 
current type system and some ideas for the future of Haskell in 
order to support type-level programming better. 



cabal install singletons. You will need GHC 7.8.2 or higher. 
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A somewhat unexpected contribution of our work is discovery 
and posting of nearly 30 GHC bugs. Of these, 15 are related to 
Template Haskell and 9 to the type checker. 

It is our hope that through the use of the singletons library, 
users will be able to experiment with type-level programming with 
ease, encouraging the use of a strongly-typed programming style. 
We, and others, will also gain more experience with code that can 
operate on both the term and type levels, to better inform the design 
that may eventually be implemented as part of a dependently-typed 
version of Haskell. 

2. Types and Kinds 

Before presenting our main work, it may be helpful to the reader to 
have a brief review of how promotion currently works in Haskell. 
This section presents no new results and may be skipped by the 
expert reader. 

2.1 Datakinds 

Haskell has long had a notion of kinds separate from that of types. 
A term is classified by a type. Thus, True has the type Bool and 
(Ax — > length x==0) has the type [a] — > Bool. A type, in 
turn, is classified by a kind, where the special kind * classifies 
normal types that have values. Thus, Bool has kind *, Maybe 
has kind *—>•★, and the StateT monad transformer has kind 
* — > (*—>•*)—>•★—>•*. 

Yorgey et al. (2012) describe how certain Haskell algebraic 
datatypes can be promoted into new datakinds. A simple example 
is Bool. The idea is that a definition 

data Bool = True \ False 

introduces a kind ' Bool with types ' True and ' False. 2 We can 
now write a datatype like 

data OperatingSystem (unixLike :: 'Bool) where 
MacOS :: OperatingSystem 'True 
Linux :: OperatingSystem 'True 
Windows :: OperatingSystem 'False 

where we annotate the OperatingSystem type with further infor- 
mation that can be used at compile-time. 

2.2 Type families 

GHC has long supported open type families (Chakravarty et al. 
2005b), and with the release of version 7.8 comes their closed 
form (Eisenberg et al. 2014). A type family can be viewed as a 
function at the type level. As such, type families enable expressive 
type-level programming. For example, we can easily define an 
IsZero function over type-level natural numbers: 

data Nati = Zero \ Succ Nati 

type family IsZero (n :: ' Nati) :: 'Bool where 

IsZero' Zero — 'True 

IsZero ( 'Succ n) — 'False 

This new feature of closed type families plays a critical role 
in the present work because they enable kind inference. Unlike 
open type families, closed type families have all of their equations 
written in one place, and so GHC can use the equations to infer the 
kinds of the type family arguments and result. Indeed, the IsZero 
example could have been written without the ' Nati and ' Bool 
kind annotations. 



2 Diverging somewhat from GHC's parser, we will annotate datakinds with 
a ' to aid the reader. 



2.3 Kind polymorphism 

Yorgey et al. also introduce kind polymorphism, which allows for 
a definition to be abstract in its kinds. For example, we can write a 
kind-polymorphic Length function over type-level lists: 

type family Length (list :: '[a]) :: 'Nati where 
Length '[] = 'Zero 
Length (x ': xs) = 'Succ (Length xs) 

In this code, note that a is a kind variable, as it classifies the 
type list. Thus, Length is kind-polymorphic. Kind polymorphism 
is naturally essential to promoting type-polymorphic functions. 

2.4 Type-level literals 

Iavor Diatchki has implemented type-level literals into GHC. 3 Two 
kinds of type-level literals are allowed: natural numbers and strings. 
The use of a numeric literal in a type will produce a type of kind 
Nat (separate from our Nati), and the GHC.TypeLits module 
exports several type families (such as + and *) that can manipulate 
Nats. The use of a string literal at the type level will produce a type 
of kind Symbol. Currently, there are no operations on Symbols 
other than equality and comparison. 

3. Promoting functions 

As examples, let's examine a few library functions extracted from 
the Data . List and Data . Maybe modules: 

span :: (a — > Bool) — > [a] — > ([a], [a]) 
span_xs@[] — (xs,xs) 
span p xs@(x : xs') 

\ p x — let (ys, zs) = span p xs' in (x : ys, zs) 

otherwise — ([},xs) 

nubBy :: (a — > a — > Bool) — S- [a] — > [a] 
nubBy eq [] = [] 
nubBy eq (x : xs) = 

x : nubBy eq (filter (Ay — > not (eq x y)) xs) 

groupBy :: (a -> a -> Bool) -> [a] -> [[a]] 
groupBy _ [] = [] 

groupBy eq (x : xs) — (x : ys) : groupBy eq zs 
where (ys, zs) — span (eq x) xs 

mapMaybe :: (a — > Maybe b) — > [a] — > [b] 
mapMaybe _ [] = [] 
mapMaybe f (x : xs) — 
let rs = mapMaybe f xs in 
case f x of 
Nothing — > rs 
Just r — > r : rs 

Now that the programmer has access to datakinds, she might 
wish to apply the functions above at the type level. These func- 
tions are all defined over terms, so she decides to simply rewrite the 
functions as type families. But she quickly encounters a problem. 
The functions above use let statements, case expressions, guards, 
higher-order functions, lambdas, partial application, where clauses, 
©-patterns and wildcard patterns. None of these features is avail- 
able at the type level, so translating above definitions to type fami- 
lies is a daunting task. 

Nevertheless it is possible to emulate all of these Haskell con- 
structs - and thus implement all of the mentioned functions - at 



3 http : //www.haskell . org/ghc/docs/7 . 8 . 2/html/users_guide/ 
type- level- literals .html 
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the type level by using only those features described in Section 2. 
The process of doing this is tedious, so we have extended the sin- 
gletons library (Eisenberg and Weirich 2012) to do the promotion 
automatically. Promotion is implemented via Template Haskell and 
generates type-level equivalents of definitions supplied by the user. 
Promotion is performed by invoking the promote function: 

$ (promote [d\ 

map :: (a ->• b) -> [a] -> [b] 

map _[] =[] 

map f (x : xs) — fx: map f xs 

ID 

A call to promote generates a type family implementing the pro- 
moted version of map as well as some auxiliary definitions required 
to make it work (details are given in Section 4.3). The functions 
above are all promotable using promote, without any edits. 

3.1 A longer example - reordering of type-level lists 

Having complex functions easily available at the type level facili- 
tates more programming in types. As a slightly longer example, we 
consider the following function, reorderBy. The reorder By func- 
tion takes an equivalence predicate and two lists, which we'll call 
xsi and XS2. The function reorders xsi to match the ordering in 
XS2, where possible. That is, all elements in xsi that are equiva- 
lent to elements in XS2 are brought to the front of the result list, 
and placed in the same order as those elements in XS2. Elements 
in xsi not equivalent to anything in XS2 are left in the same order 
and moved to the end of the result list. Extra elements in XS2 are 
ignored. 

Here is an implementation of reorderBy: 

reorderBy :: V a. (a -> a -> Bool) -> [a] -> [a] -> [a] 
reorderBy _ x [ ] = x 
reorderBy eq x (h : t) 
— case extract h x of 

(1st, Nothing) — > reorderBy eq 1st t 
(1st, Just elt) -> elt : (reorderBy eq 1st t) 
where 

extract :: a — > [a] — > ([a], Maybe a) 
extract _[] = ([], Nothing) 
extract s (h : t) 

| s l eq' h — (t, Just s) 
otherwise — let (resList, resVal) = extract s t 
in (h : resList, resVal) 

This function, when promoted, serves a critical role in the units 
library (more fully described by Muranushi and Eisenberg (2014)). 
That library allows users to type-check their code with respect to 
units-of-measure, rather like the system developed by Kennedy 
(1996). A crucial capability of such a library is to type-check the 
multiplication of two dimensioned quantities. For example, if v is a 
velocity (i.e., a Length over a Time) and we multiply by t, a Time, 
we wish to get a Length. Internally, units stores the dimensions of 
a quantity as a type-level list where order is insignificant. When 
type-checking multiplication, we must combine two such lists, 
reordering one to match the other in order to avoid duplicating a 
dimension factor. Reordering is also used to ensure that addition 
happens between two quantities of the same dimension, once again, 
neglecting the order of the type-level lists. The type signatures for 
these operations involve several other concepts related to the units 
library, and a full explanation would take us too far afield. 

As demonstrated here, a user can write normal term-level code 
and have it promoted automatically to the type level. This makes 
type-level programming much easier because the programmer can 
write his code using familiar and powerful term-level constructs 



and our library handles them under the hood. With our library, type- 
level programming also becomes more reliable: assuming the cor- 
rectness of our implementation, it is possible to test correctness of 
term level functions using QuickCheck or HUnit and be confident 
that the promoted functions generated from tested definitions be- 
have correctly. Testing hand-written type-level code is not as sim- 
ple. 

3.2 Promoted Prelude 

Our library provides modules containing promoted functions from 
the standard Prelude as well as five other modules from the base 
package: Data. Bool, Data. Either, Data. List, Data. Maybe 
and Data. Tuple. These serve both as a convenience for users as 
well as a test of the robustness of our approach. The five Data 
modules mentioned above export a total of 125 functions. Out 
of these, we were able to promote 91 simply by wrapping the 
implementation from the base library in a Template Haskell quote 
and calling our promote function. Out of the 34 unpromotable 
functions: 

• 18 functions are not promotable because they manipulate Int 
or Integral type-class values, or because they rely on functions 
that do so and thus have Int in their type signature. However, it 
is possible to promote all of these functions if they are rewritten 
to use Nat, the kind of type-level numeric literals. For example: 

$ (promoteOnly [d\ 
length :: [a] — ► Nat 
length [] =0 
length (_ : xs) — 1 + length xs 

ID 

promotes correctly. 

• 6 are not promotable because they use list comprehensions. 
They become promotable if we rewrite them to explicitly use 
map and filter functions. 

• 4 functions are not promotable because they operate on strings. 

• 5 functions are not promotable because they work with infinite 
lists and thus generate infinite types, which are not allowed in 
Haskell. 

• 4 functions are not promotable because the promoted function 
name clashes with existing datatype. See Section 4. 1 . 

Section 5 gives more detail about why the other functions were 
not promotable. The numbers above don't sum to 34 because some 
functions fall into several categories. For example, findlndices 
function uses list comprehensions, infinite lists, and integers. Some 
of the mentioned limitations have workarounds. After applying 
them we are left with only 7 functions that can't be promoted: 3 
that return infinite lists and 4 that work on strings. 

4. Promotion algorithm 

Up until now, we have seen calls to our promote function. This 
section gives the gory details of how it works, under the hood. 

4.1 Naming conventions 

Promotion is performed by generating new Haskell definitions from 
definitions supplied by the user. Thus, we adopt some naming 
conventions so that programmers can later access the generated 
type-level definitions. Figure 1 shows typical examples and the 
full set of special cases. Occasionally, these conventions cause a 
conflict, such as for the either function and the Either datatype. 
In these cases, our version of the Prelude appends an underscore 
to avoid the conflict. Thus, our promoted either function is named 
Either . 
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Term-level 


Promoted 


Symbols 


map 


Map 


MapSymO, MapSyml , MapSym2 


++ 


: ++ 


:++$, :++$$, :++$$$ 


Just 


'Just 


JustSymO, JustSyml 









Special cases: 

[] 
J 

(.) 
(#,#) 
undefined 



NilSymO 



Tuple2SymO, Tuple2Syml, 
Tuple2SymO, Tuple2Syml, 
Any 



Figure 1. Examples demonstrating how names are transformed. 
See Section 4.3 for more information about symbols. 



4.2 Preprocessing 

The promoted definitions are generated using Template Has- 
kell (Sheard and Peyton Jones 2002). Users quote the code they 
wish to promote in a declaration quote [d\ ... |], which converts 
source Haskell syntax into the Template Haskell abstract syntax 
tree (AST). 

Template Haskell's AST is quite large, as it intends to represent 
all of the constructs available in Haskell. However, many of these 
constructs are redundant. For example, Template Haskell maintains 
the distinction between (listl ++ Iist2) and ((++) listl Iist2), even 
though these expressions have the same meaning. Thus, to make 
our task easier we wrote the th-desugar library. 4 This library con- 
verts the Template Haskell AST into a smaller core language. For 
example, if expressions are converted to case expressions with 
True and False branches, and where clauses are converted to let 
declarations. This preprocessing step is not mandatory to imple- 
ment our approach - and in fact initially we did not perform it - 
but it allows us to focus on promoting a small core set of features 
instead of dealing with promoting constructs that are just syntactic 
sugar. 

The th-desugar AST is presented in Figure 2 and more fully 
described in Section 6.1. All Haskell constructs are representable 
retaining their original meaning in this more condensed AST. 

4.3 Functions and partial application at the type level 

Functions at the type level and functions at the term level have dif- 
ferent syntactic properties in Haskell. At the term level, functions 
are curried so it is natural to use partially applied functions. By 
contrast, calls to type-level functions in Haskell must be fully satu- 
rated (Chakravarty et al. 2005a), as allowing partially applied type 
functions wreaks havoc with type inference (see Section 7.1). 

So, how to possibly promote a partially applied term-level func- 
tion? We use the technique of defunctionalization, as first put for- 
ward by Reynolds (1972). The fundamental idea of defunctional- 
ization is that functions are represented by opaque symbols, which 
are then applied to their arguments via a special application opera- 
tor @@. Nested uses of @@ can apply a symbol to multiple arguments. 
We define @@ to be an ordinary open type family, so that we can add 
equations for new symbols at any time. 

During promotion, we generate symbols for type families 
and data constructors. The name of a defunctionalization sym- 
bol in our implementation is created by appending SymO (for 
alphanumeric identifiers) or $ (for operators) to the name of the 
type-level function. Thus, the expression isjust Nothing pro- 
motes to IsJustSymO @@ NothingSymO and map pred [ ] pro- 
motes to MapSymO @@ PredSymO @@ NilSymO. As usual, @@ is 



left-associative. In these examples, we see that all top-level iden- 
tifiers are promoted to symbols. This is because Template Has- 
kell offers no access to the types of terms, and thus our imple- 
mentation cannot tell a partially applied function from a fully ap- 
plied constant. We take the only way out and define, for example, 
type NothingSymO = ' Nothing during promotion. It is then safe 
and correct to append every promoted identifier with SymO or $ 

4.3.1 The kind -» 

Because symbols are not functions, the kind of a symbol must not 
be built with — K Instead, we introduce the new kind -» (associ- 
ating to the right, like — >) to classify symbols. Thus, the kind of 
MapSymO is (a -» b) -» '[a] -» '[£>]. 

Unlike closed promoted datatypes, though, we must be free to 
create new members of -» at any point in the program - it is a 
fundamentally open kind. Thus, we hook into Haskell's facility to 
introduce new, opaque, type-level constants through its datatype 
declaration mechanism. We wish to be able to say 

data MapSymO :: (a -» b) -» '[a] -» '[£>] 

using an explicit kind annotation on the datatype declaration. Here, 
we must be careful, though: all types that contain values must be 
of kind * in GHC. 5 Thus, GHC requires that the kind of a datatype 
end in ...—>•*, as datatypes are normally meant to hold values. We 
can now figure out how -» must be defined: 

data TyFun - only the promoted form is used 

kind a -» b — ' TyFun a b — > * 

where the second line uses a hypothetical syntax to introduce a kind 
synonym. Expanding this definition for -», we see that the kind of 
MapSymO indeed ends with ...—>■* as required. 

In our actual implementation, we have no kind synonyms, and 
we are left with using the more verbose TyFun routinely. 

4.3.2 The @@ type family and its instances 

The application operator @@ is defined as an open type family; new 
instances (i.e., equations) of this family can be written at any time. 
Its definition is quite naturally 



type family (f :: kl -» k2)@@ (x :: kl] 



k2 
k2) 



(kl -> k2) 



1 cabal install th-desugar 



Rewriting somewhat, the kind of @@ is (kl 
- it converts a symbol into a real function. 

To write the instances for our defunctionalized symbols, we 
must create a new symbol for every level of partial application. For 
example, Map might be totally unapplied, be given one argument, 
or be given two arguments. Thus, we get three symbols, MapSymO, 
MapSyml , and MapSym2, with kinds as follows: 

MapSymO :: (a -» b) -» '[a] -» '[6] 
MapSyml :: (a -» b) -> '[a] -» [b] 
MapSym2 :: (a -» b) -> [a] -¥ [b] 

Note how the choice of arrow changes between symbols. MapSymO 
must appear with @@ to use it at all, whereas MapSyml takes its 
first argument without @@. Indeed, the number assigned to a symbol 
denotes its honest-to-goodness arity as a GHC type. 

With these definitions in hand, the instances for @@ are straight- 
forward: 

type instance MapSymO @@ f = MapSyml f 
type instance (MapSyml f) @@xs = MapSym2 f xs 
type MapSym2 f xs = Map f xs 

type family Map (f :: a -» b) (xs :: '[a]) :: '[6] where ... 

5 We ignore here, and throughout, the existence of the kind # that classifies 
unlifted types. 
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The definition for MapSym2 is not strictly necessary in our 
scheme; it is included to parallel the non-function case (such as 
NothingSymO, above). 

4.3.3 Kind inference 

It is essential that the kinds of the symbols be correct for the pro- 
moted code to kind-check. But, given that Template Haskell is not 
type-aware, how are these kinds determined? At first glance, the 
problem seems easy: just look at top-level type signatures. After all, 
it would seem to be a reasonable burden to ask programmers keen 
on type-level programming to write top-level annotations for their 
definitions. However, these top-level annotations turn out to be in- 
sufficient. As we will shortly see, we use the technique of lambda 
lifting (Johnsson 1985) to deal with anonymous functions within 
expressions. Lambda-expressions tend not to have any type anno- 
tations, and it would be annoying to users to require annotations 
here, both on arguments and on the return value. So, we must strive 
for something better. 

To get the kinds right for the symbols, we wish to propagate the 
kinds up from the type family representing the function at hand. 
Let's continue to consider the Map example. The type family Map 
is given explicit kind annotations (produced from map's top-level 
type signature), but its kinds could also have been inferred by GHC. 
Then, the type MapSym2, a simple type synonym for Map, also 
gets the correct kinds, via simple kind inference on the definition 
for MapSym2. Thus, we have MapSym2 :: (a -» b) — > '[a] — > 
'[b]. To see how MapSyml and MapSymO get their kinds, let's 
look at their full definitions: 

type KindOf (a :: k) = ( ' K Proxy :: KProxy k) 
— defined once for all symbols 

data MapSyml x f where 
MapSyml Kindlnference 

:: KindOf ((MapSyml x) @@ arg) 
~ KindOf (MapSym2 x arg) 
=> MapSyml x f 
data MapSymO f where 
MapSymOKindlnference 

:: KindOf (MapSymO @<S arg) 

~ KindOf (MapSyml arg) 
=> MapSymO f 

Much like in the old days before explicit kind annotations, we use 
dummy data constructors to constrain the kinds of the symbols. 
The KindOf type synonym discards the types, leaving only the 
kinds. This turns out to be crucial, because the discarded types are 
ambiguous; without KindOf, GHC reports ambiguity errors for 
these data constructors. In the definition for MapSyml, we see 
that the type variable x is used as an argument to MapSym2. 
This fixes the kind of x to be (a -» b). We then see that 
KindOf ((MapSyml x)@@arg) ~ KindOf (MapSym2 x arg) 
So, (MapSyml x)@®arg and MapSym2 x arg must have the 
same kinds, specifically '[£>]. Given that @@ has the correct kind, 
this means that (MapSyml a) must have the correct kind (that is, 
'[a] -» '[/>]), and thus that the type variable f has the right kind 
(that is, TyFun '[a] '[b], unrolling the definition for -»). Putting 
this all together, we see that MapSyml :: (a -» b) — > '[a] -» '[b], 
as desired. A similar line of reasoning gives us MapSymO :: (a -» 
b) -» '[a] -» '[b]. 

4.3.4 77-expansion 

There is one corner case we must handle during function promo- 
tion. Haskellers often 77-reduce their definitions where possible - 
that is, the type of a function may have more arrows in it than pat- 
terns in the function's clauses. A convenient example is zip: 



zip::[a]^[b]^[(a,b)] 
zip = zip With (, ) 

A naive promotion of zip would give us Zip :: ' [a] -» ' [b] -» 
'[ '(a,b)]. This promotion would not correspond to users' intu- 
itions - the kind has the wrong arrows! We would want to be able 
to say Zip '[Int, Bool] '[Char, Double] and get '[ '(Int, Char), 
'(Bool, Double)]. Instead, users would have to use @@ to use Zip. 

The solution to this is straightforward: 77-expansion. When pro- 
moting zip, we actually promote the following version: 

zip,.[a]^[b]^[(a, b)] 

zip erai eta 2 = zipWith (, ) erai era 2 

This 77-expansion is done only when there is a type signature to 
signal the need for expansion. 

4.4 Datatypes 

At the term level, data constructors can be used in any context ex- 
pecting a function. We want to have the same uniformity at the 
type level. We rely on GHC's built-in promotion mechanism to pro- 
mote datatypes, and it does most of the work for us. 6 However, we 
must generate the defunctionalization symbols manually. For ev- 
ery data constructor, we generate symbols and @@ instances in the 
same way we generate them for promoted functions. This symbol 
generation may seem somewhat redundant for promoted data con- 
structors, because they are allowed to appear partially applied in 
programs. Nonetheless, given that — > and -» are distinct kinds, we 
must defunctionalize the data constructors to achieve uniformity 
with promoted functions. 

By using GHC's mechanism for datatype promotion, we run 
into one technical snag. During promotion, all arrows — > become 
defunctionalized arrows -». Since GHC does not apply this trans- 
formation during its promotion of datatypes, promoted datatypes 
that store functions will not work correctly. For example, while 
promotion of the following Arr datatype will succeed, promotion 
of the arr Apply function will fail due to a kind mismatch: 

data Arr a b = Arr (a — > b) 

arr Apply :: Arr a b — > a — > b 
arrApply (Arr f) a = f a 

We could solve this problem by implementing our own datatype 
promotion mechanism using Template Haskell. That design would 
be awkward for the programmer, though, as there would be two 
promoted versions of each datatype: one generated by GHC and 
another one by us, with slightly different names. 

4.5 case expressions 

A case expression inspects a scrutinee and selects an appropriate 
alternative through pattern matching. The only way we can perform 
pattern matching at the type level is via a type family. Thus, we turn 
case expressions into fresh closed type families. Each alternative in 
the original case becomes a defining equation of the type family. 
We must, however, remember that case alternatives may use local 
variables bound outside of the case expression. Since type families 
are top-level constructs, an equation's RHS can use only bindings 
introduced by the patterns in its LHS. Therefore, when promoting 
a case expression to a type family, we pass all in-scope bindings 
as parameters to the type family - much like in lambda lifting. The 
scrutinee itself is the last parameter. 

Here is an example from the Data . Maybe module: 



6 We make no attempt to detect datatype definitions that can't be promoted 
by GHC, for example GADTs. We naturally cannot promote these datatypes 
either. 
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fromMaybe :: a — > Maybe a — > a 
fromMaybe d x = case x of 

Nothing — > d 

Just v — > v 

This function promotes to the following: 7 

type family Case d x scrut where 
Case d x 'Nothing — d 
Case d x ( 'Just v) = v 

type family FromMaybe (tl :: a) (t2 :: 'Maybe a) :: a 
where 

FromMaybe d x = Case d x x 

The case expression is promoted to the type family Case and its 
application on the RHS of FromMaybe. Local variables d and x, 
both in scope at the site of the case statement, are passed in, along 
with the scrutinee, also x. In the definition of Case, the scrutinee 
- that is, the third parameter - is matched against, according to the 
original, unpromoted definition. 

It is conceivable to do a dependency check to eliminate the 
redundant second parameter to Case. We have not implemented 
this as we suspect that benefits of such an optimization would be 
small, if any. 

We also note that, because this type family Case is used only 
once and is fully applied, there is no need to create the defunction- 
alization symbols for it. 

4.6 Lambda expressions 

Promoting an anonymous function poses two difficulties. Firstly, 
lambdas, like all functions, are first-class values that can be passed 
around and partially applied. Secondly, the body of a lambda can 
use variables bound in the surrounding scope - the lambda can 
define a closure. For example, in the dropWhileEnd function from 
the Data. List module, p is used inside a lambda body but is 
bound outside of it: 

dropWhileEnd :: (a -> Bool) -> [a] -> [a] 
dropWhileEnd p = foldr (Ax xs — > if p xSzSz null xs 

then [] 
else x : xs) [ ] 

Happily, we have already solved both problems, making promo- 
tion of lambdas straightforward. A lambda expression promotes to 
the use of a fresh type family, along with the family's definition. 
Just like with case, all in-scope local variables are turned into ex- 
plicit parameters. The technique we use here is, of course, lambda 
lifting (Johnsson 1985). 

The major difference between lambdas and case expressions is 
that, for lambdas, we must generate symbols so that the lambda 
can be partially applied and passed around as a first-class value. 
The freshness of the type family name prevents a programmer from 
explicitly calling type families that encode promoted lambdas. The 
result of promoting dropWhileEnd looks like this, omitting the 
tiresome symbol definitions: 

type family Case p etai x xs scrut where 
Case p etai x xs ' True = NilSymO 
Case p etai x xs ' False — ( : $) <3@ x @@ xs 

type family Lambda p etai x xs where 
Lambda p etai x xs — Case p etai x xs 
((:&&$) @@ (p@@x) <§@ (NullSymOmxs)) 

type family DropWhileEnd (p :: a -» Bool) 

(etai ■■ [a]) :: [a] where 

7 Here and elsewhere, we omit various decorations put on generated names 
to guarantee freshness. 



DropWhileEnd p etai = 

(FoldrSymO @@ (LambdaSymO @@ p @@ etai) 
@@ NilSymO) @@ etai 

4.7 let statements 

A let statement introduces a set of (potentially recursive) local 
bindings. Since there is no local binding construct available at the 
type level, we must once again lift let bindings to the top level. As 
we have done elsewhere, each let-bound name is freshened to guar- 
antee uniqueness. Let-lifting differs in an important respect from 
case- and lambda-lifting: let-bound identifiers have an unfolding, 
unlike case- and lambda-bound identifiers. Thus, we do not pro- 
mote a let-bound identifier into a type variable, but instead into a 
call of the top-level definition generated by the identifier's declara- 
tion. 

Consider this function: 

doubleSucc :: Nati -»■ Nati 
doubleSucc x = let y = Succ x 
z — Succ y 
in z 

In this example, x is bound in the scope surrounding the let- 
statement, y appears both as a variable binding and on the right- 
hand side of another binding, namely z, while z itself appears as a 
variable binding and inside the body of the let. The y and z bind- 
ings will be lifted to become top-level identifiers (type synonyms 
in this example) that accept x as parameter. Since the names of y 
and z will be fresh, we must build a substitution from the original 
let-bound identifier to a promoted, freshened identifier applied to 
all local variables in scope. Thus, the promoted code will look like 
this: 

type LetY x — SuccSymO®@x 
type LetZ x = SuccSymO ®@(LetYSyml x) 
type family DoubleSucc (a :: Nat) :: A/at where 
DoubleSucc x — LetZSyml x 

Notice how x, which was bound in the scope surrounding the 
let-statement, became an explicit parameter of every lifted let- 
declaration. It is also passed in at every use site of these lifted let- 
bound identifiers. 

Recursive let-bindings do not pose any particular problem here, 
as type families may be recursive. A recursive definition that leads 
to an infinite data structure, however, is problematic - GHC does 
not permit infinite types. See Section 5 for more discussion. 

4.8 Type classes and instances 

Type classes enable several different programming capabilities. We 
review how these manifest at the type level before presenting our 
promotion strategy. 

4.8.1 Ad hoc polymorphism 

A Haskell type class enables ad hoc polymorphism, where one 
function can have different implementations at different types. The 
notion of an explicit type class is made necessary by the lack of a 
type-case. For example, consider the following bogus definition: 

sometimesNot :: V a. a — > a 

sometimesNot x — typecase a of Bool — > not x 

— > x 

Here, we check the instantiation for a at runtime and make a 
decision on how to proceed based on the type a. This is, of course, 
not possible in Haskell - it would break both type erasure and 
parametricity. When a user wants functionality like sometimesNot, 
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she uses a type class. The use of this type class then appears in the 
type of sometimesNot: 

sometimesNot :: SupportsSometimesNot a => a — > a 

By including the type constraint there, the type advertises that it is 
not strictly parametric in a. 

Promoting this concept is made easy by one simple fact: 
type families are not parametric in their kinds! In other words, 
a type family can pattern-match on the kinds of its arguments, 
not just the types. The following promotion of the original, bogus 
sometimesNot is perfectly valid: 

type family SometimesNot (x :: a) :: a where 
SometimesNot (x :: Bool) = Not x 
SometimesNot x = x 

In this type family, we match on the kind of the parameter to choose 
which equation to use, making this a kind-indexed type family. 
We should note that such action does not cause trouble with type 
erasure, as both types and kinds are compile-time constructs. 

4.8.2 Open functions 

A normal Haskell function is closed. All of its defining equations 
must be listed in one place. A type class method, on the other 
hand, is open, allowing its defining equations to be spread across 
modules. Promoting an open function is thus easy: use an open type 
family. 

4.8.3 Method defaulting 

Type classes also permit the possibility of method defaults. This is 
evident in the definition of Eq: 

class Eq a where 

(==)> (/=) :: 3 -> a -> B ° o1 
x —— y = not (x /= y) 
x /= y = not (x == y) 

If an instance does not supply a definition for one of these methods, 
the default is used. Happily, GHC provides a similar capability 
through associated type families. GHC accepts an associated type 
family default, much like a method default. The default is used only 
when an instance does not supply another definition. 

4.8.4 Promotion 

The first two capabilities above - ad hoc polymorphism and open 
functions - seem to suggest that we promote a class declaration by 
rewriting all of its methods as open type families and not to bother 
promoting the class itself. However, method defaulting, which is 
much used in practice, tells us that we somehow need to package 
these type families in a new class definition in order to make the 
open type families associated, and hence defaultable. 

To promote a type class, then, we need a kind classl Though the 
syntax is somewhat burdensome, GHC supports kind classes via a 
poly-kinded type class definition where the type itself is irrelevant. 
Putting this all together, here is the promotion of Eq: s 

data KProxy (a :: *) = KProxy — in Data. Proxy 
class (kproxy ~ 'KProxy) 

=> PEq (kproxy :: 'KProxy a) where 

type (x :: a) :== (y :: a) :: Bool 

type (x :: a) :/= (y :: a) :: Bool 

type x :== y = Not (x : /= y) 
type x :/= y = Not (x :== y) 



8 The definition exactly as stated does not work in GHC 7.8.2, due to a bug 
in kind-checking associated types. It is reported as GHC bug #9063 and can 
be worked around via kind annotations on the default definitions. 



We make use here of the type KProxy, which when promoted, 
is a type-level proxy for a kind argument. Its definition restricts its 
type parameter a to be of kind * so that the type is promotable; 
GHC does not promote poly-kinded datatypes. However, the type 
is intended to be used only when promoted. 

The class declaration head now takes a type-level proxy for the 
kind-level argument a. In other words, PEq is properly a kind class, 
as desired. (The kproxy ~ ' KProxy constraint forces the term- 
level argument kproxy to be irrelevant. It is necessary for recursive 
definitions to type check.) 

Instance promotion Given all the work above, promoting in- 
stances is quite straightforward: we promote the instance head to 
use a KProxy parameter and promote method bodies just like nor- 
mal functions. GHC's built-in defaulting mechanism does the de- 
faulting for us. 

Constraint promotion How do we promote a constrained func- 
tion? We simply drop the constraints. Making a type family asso- 
ciated with a class attaches the type family parameters to the class 
parameters (enabling more kind checking) and allows for default- 
ing. But, using an associated type family does not induce the need 
for a class constraint. This is crucial, because there is no way of 
writing a constrained type family instance. Thus, we safely ignore 
any class constraints during promotion. 

If we just drop constraints, couldn't a user call an associated 
type family at the wrong kind? (For example, consider (:==) at 
Bool — ¥ Bool.) Yes, this can happen, but nothing bad comes from 
it - the type family just does not reduce. Types being stuck cause 
no problems; they are just empty types. This, of course, is quite 
different from terms being stuck, which generally leads to a crash 
of some sort. 

Deriving Eq, Ord and Bounded If a datatype derives the Eq, 
Ord or Bounded classes, we automatically derive the promoted 
instance. Other derivable classes are currently ignored. 

4.9 Other language features 

Below we list other language features present in Chapters 3 and 4 
of the Haskell 2010 Language Report that were omitted in earlier 
discussion. 

Records: Promotion of records is fully supported. For datatypes 
declared using record syntax, th-desugar generates appropri- 
ate accessor functions. Record update, construction and pattern- 
matching syntax are desugared into simpler constructs that rely 
on simple pattern matching, case expressions and datatype con- 
struction. There is one restriction on record promotion: a record 
datatype definition must be promoted in a separate Template 
Haskell splice from its use sites. This is a limitation in the th- 
desugar library, which can look up record field names only in a 
splice that has already been type-checked. 

Type signatures on expressions: We promote type-annotated ex- 
pressions to kind-annotated types. 

Errors: The Haskell 2010 Language Report defines error and 
undefined functions that cause immediate program termina- 
tion when evaluated. Both these functions represent _L and in- 
habit every type. We don't have type-level expressions that 
cause type-checking termination when evaluated, but we can 
have types that belong to any kind. Furthermore, it seems rea- 
sonable to equate _L with a "stuck" type - a type-level expres- 
sion containing a type family but unable to progress. Thus error 
promotes to the Error open type family: 

type family Error (a :: Symbol) :: k 
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This family has no instances, so it is always stuck. Along 
similar lines, undefined promotes to Any, a special type in 
GHC belonging to any kind. 

Other syntactic sugar: This catch-all entry includes if condition- 
als, operator sections, and pattern guards. These are eliminated 
by the th-desugar preprocessing pass, in favour of case state- 
ments (for conditionals and guards) or lambda-expressions (for 
sections). 

5. Limitations 

Earlier work on this subject (Eisenberg and Weirich 2012) listed 
language features that were either not yet supported by the single- 
tons library or problematic to implement. We can now state that 
almost all such features are now implemented and fully supported. 
Exceptions include the following: 

Infinite terms: While it is possible to construct infinite terms 
thanks to laziness, it is not possible to construct infinite types. 
Therefore, it will not be possible to use any promoted expres- 
sion that generates such a type. A good example of this is the 
iterate function found in the standard Prelude: 

iterate :: (a — > a) — > a — > [a] 
iterate f x = x : iterate f (f x) 

The promotion itself does not fail, but any attempt to use pro- 
moted Iterate does. This example also demonstrates another 
shortcoming of the current implementation. Our algorithm op- 
erates in an untyped setting and only reports errors when the 
algorithm gets stuck. This means we can generate definitions 
that are unusable. At the moment, the responsibility of identi- 
fying such a problem rests on the programmer. 

Literals: We rely on GHC's built-in promotion of literals, so our 
approach is limited by GHC's capabilities. At the moment, 
promotion of integer literals to type-level Nats is supported, 
but this approach has drawbacks: negative integer literals do 
not promote, and the types do not work out - the type Int does 
not promote to the kind Nat. 

String literals also present a problem, mainly because after 
GHC promotes them to the type level they are no longer con- 
sidered lists of characters. This means, for example, that it is 
impossible to promote code that concatenates two string liter- 
als using (++). It seems to us that it is impossible to bridge this 
gap with the current implementation of type-level strings within 
GHC. 

Datatypes storing functions: We do not support the promotion of 
datatypes that store functions. See Section 4.4 for details. 

do-notation: th-desugar preprocessing desugars do-notation along 
the lines of the desugaring described in the Haskell Report. This 
creates lambda-expressions composed using monadic bind op- 
erators. While lambdas and operators are by themselves pro- 
motable, the types of monadic operations pose a problem. They 
involve a higher-kinded type variable (the m in Monad m). 
Haskell's support for kind variables does not have a system of 
classifying kind variables. That is, there is no such thing as a 
"higher-sorted" kind variable. If we were to try to promote the 
type of (»=), we would have to get ma — > (a -» mb) mb. 
Here, we've removed the need for higher sorts by writing what 
should be m a as the single variable ma. But, we have no way 
of expressing relation between ma and a in the type signature 
of a hypothetical (:^=) type family. It is possible to put explicit 
type annotations on hand-written monadic expressions to guide 
GHC's kind inference and have them promote correctly. But 



doing so for desugared do-notation would require us to write 
our own type inference. Thus, do-notation is not promotable. 

List comprehensions: These are syntactic sugar for monadic no- 
tation and thus do not promote for exactly the same reasons as 
do-notation. 

Arithmetic sequences: These rely on the Enum type class, which 
is implemented using integers and infinite lists. Integers can 
be worked around with Nats. Infinite lists however are a more 
fundamental problem, as we discussed above. 

Show and Read type classes: These rely critically on string ma- 
nipulation, which is not available on type-level Symbols. 

Fixity declarations for datatypes: Due to a Template Haskell 
bug, fixity declarations for capitalized identifiers (including 
symbols beginning with ":") currently do not work. 9 

6. Formalization and proof 

The process we describe in Section 4 is rather involved. In this 
section, we present a formal grammar for a subset of Haskell and a 
promotion algorithm over this grammar. We then prove that 

• promoting a well-typed, promotable term yields a well-kinded 
type, and 

• assuming lambda-lifting is correct, the semantics of a promoted 
term lines up with that of the original term. 

Both the formal promotion algorithm and the proof are done in 
two stages. First, we promote (written as a postfix -ft-) expressions 
into extended types, written r, which contains the grammar of 
types r but also includes anonymous functions, and case and let 
expressions. We then reduce this extended type language into the 
language of ordinary types through the operation [-J^, discussed 
more in Section 6.3. 

6.1 The formal grammar 

The grammar we work with is presented in Figure 2. 10 Much of the 
first part of this figure - a rendering of the actual AST used in our 
implementation - is rather standard for Haskell. There are a few 
points of interest: 

Literals: Literals are included as (lit) in the definition of expres- 
sions e, as literals form part of the AST used in our implementa- 
tion. However, as promotion of literals does disrupt their typing 
and semantics, we omit them from the rest of this section. 

let declarations: let-declarations S include a bound variable x, 
an optional signature a, and a list of function clauses W e. 
Note that each clause is a list of patterns W mapping to a single 
expression e. 

Type family applications: The grammar for types r includes type 
family application F(t). This is written with parentheses to 
emphasize the fact that type families must always appear fully 
saturated. As implemented in GHC, this is properly part of the 
syntax, not part of the type system - any use of a bare type 
family F is malformed. 

Kind schemes: Although kind schemes ip cannot be written in 
Haskell, a Haskell programmer using kind-polymorphism must 
consider these, which classify type constructors and promoted 
data constructors. 

Figure 2 includes also the definition for the contexts used in the 
typing judgements and proofs. 

9 See https : //ghc . haskell . org/trac/ghc/ticket/9066 

10 Our formalism was developed and typeset using Ott (Sewell et al. 2010) 
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Data constructors K 
Type constructors T 
Type families F 



(lit) 



Metavariables: 

Termvars x, y 
Type vars a, (3 
Kind vars X,y 
Core th-desugar grammar: 
e ::= x \ K \ ei e 2 | Ax i-> e 

case e 0 of 7r F£ e | let 5 in e | e :: r 
7r ::= s | i^Tf | _ 

S ::— (x :: a){lf t-¥ e} \ x{W e} 
T:--a\(^)\T 1 T 2 \'K \ T\t :: k\F(t) 
a ::=V a. a | r 
k ::= ^ | ' T k | fti — > K2 | * 
tp::=\/X.ip\K 
Top-level declarations: 
dec ::= type F tvb = r 

type family F tvb where fur' 
tvb ::= a | a :: ft 

Grammar for extended types: 
f::=a\(->)\TiTi\'K\ T 



Expressions 

Patterns 

let declarations 

Types 

Type schemes 
Kinds 

Kind schemes 
Declarations 
Type var. binders 



f :: k | F{f) Extended types 
\a i y t | case tq of r h->- f | let uJ in f 
: (a :: ?/>){t ^ I ^ Type-let decls. 



r, x:t I T, x:a \ T, a:n \ Y, X 

F,a:K\r,a:ip\f,X 

0 . x i — y e I 9, q i-> t 



Type contexts 
Ext. type contexts 
Substitutions 
Environments 



Other notation conventions: 

Sym n (K) and Sym n (F) mean the nth symbol derived from K 

and F, respectively; these are both type constructors T. 
Lambda, Case, and Let(a) are fresh names for type families F. 
(<3@) is a type family F; (-») is a type constructor T. 
(— and (-») associate to the right; (@@) to the left. 
tvs(T) and fc«;s(r) extract bound type and kind variables, resp. 
ftv(f ) and fkv{ji) extract free type and kind variables, resp. 

Figure 2. The grammar for the th-desugar subset of Haskell, 
along with other definitions used in our proof. 



Our notation for lists is optimized for brevity, sometimes at the 
risk of introducing ambiguity. We frequently simply use an overbar 
to represent a list. When the length of the list is relevant, we write it 
as a superscript, thus: f" . As we never have nested lists, we conflate 
appending with concatenation: r, r' adds one element to the list r, 
while t , t' concatenates two lists. 

6.2 Promotion algorithm 

Figure 3 contains the formal promotion algorithm. This algorithm 
is appropriately partial. For example, the cases for promoting a 
type are quite limited; we cannot promote type families or already- 
promoted data constructors. When no equation in the algorithm 
statement is applicable for a given r, then does not exist. If 

does not exist, then neither does any form containing r'fr. 

Variables are promoted to fresh variables. For example, the 
variable is a type variable (like a), but is distinct from other 
as. In other aspects, x-ft- is an ordinary type variable, making a type 
scheme like V rr-fr.r well-formed. 

This algorithm performs defunctionalization. This can be seen 
in the definitions for K^f, (ei e2)fT, and (n — > T2)fT - all promoted 
functions are defunctionalized and must be applied using @@. No 
expression form promotes to a standard type-level application. 

Patterns promote to standard, non-extended types. This fits well 
with the use of types as patterns when defining type families. 



Context promotion (r-ft- 

0-fr 

(F,x:r)it 
(F,x:a)it 
(r, a:*)lt 



f'): 

: 0 

= rfr, x'fi'.a'fi 



Expression promotion (e-fp := f): 



%1t 

Kt 

(ei e 2 )fT 
(A x >-> e )fr 
(case eo of 7r i— > e)ff 
(let 5 in e)fr 
(e :: r)fr 

Match promotion: 

(tt ^ e)fr 

Pattern promotion (n^f := 



= x-ft 
= Sym 0 (K) 
= eil>@@ e 2 t 
= Ax"ft i — y efr 
= case eoft of 7r i — ^ eff- 
= let in eff 
= eff :: rff 

= 7rff i — ^ eff 
= t): 



xfr 

'ifTffr 



Let declaration promotion (5ff := w): 

(x :: cr){7f i-> e}ff := (xff :: crff){7f 
x{tt i-> e}ff := xff{7f eff} 

Clause promotion: 

(7f i-> e)ff := 7fff i-> eff 

Type promotion (rff := k): 



(if promotable) 
(a fresh) 

^fr} 



aff 
(ti -> r 2 )ff 
(Tr)ff 
(t :: «)fr 



= aff 

= riff ^> r 2 ff 

= Trff 

= rit 



Type scheme promotion (aff := ip): 
(Va.r)ff := Vaff.rff 
rff := rff 



Figure 3. Promotion algorithm. The promotion operator ff implic- 
itly distributes over lists. The (K promotable) condition refers to 
whether or not GHC can promote K\ see Section 3.3 of Yorgey 
etal. (2012) for details. 



Contexts are promoted to extended contexts. The only differ- 
ence between an extended context and a regular one is that extended 
contexts may contain bindings of the form a:ip. In Haskell, type 
variables always have a monomorphic kind; only top-level defini- 
tions such as data or type constructors can be kind-polymorphic. 
Thus, the a:tp form must be excluded from regular contexts. On 
the other hand, extended types need bindings of this form to sup- 
port type-level let over kind-polymorphic functions. 

6.3 Reduction algorithm 

After promoting an expression to an extended type, we then reduce 
it back into a regular type. This process entails rewriting the type to 
fit into the grammar of regular types and emitting top-level type 
and type family declarations as appropriate. The algorithm ap- 
pears in Figure 4. Unlike promotion, reduction is a total operation 
- it has no possibility of failure. 

Reduction on extended types, written \ t\ %, is parameterized by 
a list of free type variables /3 and a substitution from type variables 
to types 0. The local variables j3 are necessary when working 
with fresh top-level declarations in order to pass these variables 
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Reduction of contexts ( |_f J = F'): 

[0\ ■— 0 
[{T,a:K)\ := \Y\,a:n 
[(Y,a:^)\ := Lrj 
[(T,X)\ := [T\,X 

Reduction of extended types ([f\j = r'): 





= 0(a) 


L(->)Jf 


= (->) 


iTl^jf 


= InJf lAlf 




= 'AT 


LTJ F 


= T 


|_f :: kJ| 


= ItJ| :: K 


\_m\j 


= f (l?JI) 




= Sym n (Lambda) 



=> type Lambda /3 a = |f Jp.a 
[case-To of T i ^ f'J^ := Case(/3, |foJ;g-) 

=> type family Case /3 a where \r <-¥ t']j 
where a is fresh 
Lletwinfj|:= [t^ 0 ' 

where 0' = L^j| 

Lifting of type-level case match to type family equation: 
\r h-> fl|:= Case(Ar) h-> L^'J^M 

Reduction of type-level let decl. to subst. (L^J^ = &')'■ 

[(a :: V){t i-^ f'}J^— a H- Sym„(Let(a)) ^" 
La{r ^ f'}J^:= a^Sym n (Let(a))^" 

Lifting of type-level let declaration to top-level declaration: 

\(a ::yX.K^> K 0 ){¥^f'}-\^:= 

type family Let(a) P (f3[ :: Ki) where a \T <-¥ f'~\j 

where n = length r and the /?' are fresh 
\a{r ^f'}l|:= 

type family Let(a) /? /? where a [f H> f']j, 

where n = length r and the /?' are fresh 

Lifting of type-level clauses to type family equations: 
a \r^r%:= Let(a)(^,r) ^ 



Figure 4. Reduction algorithm from extended types to regular 
types. Both operations (reduction and lifting) distribute over lists. 



as parameters. The substitution 6 maps let-bound variables to their 
lambda-lifted equivalents. 

For example, consider stutter and its promotion: 

stutter :: [a] -> [a] 
stutter (x : xs) = 

let cons ys = x : ys in 

cons (cons xs) 

type family Stutter (xs :: '[a]) :: '[a] where 

Stutter (x ': xs) = LetConsSym2 x xs<3<3 

(LetConsSym2 x xs @@xs) 
type family LetCons x xs ys where 

LetCons x xs ys — (:$) (3(3 x OS ys 



(n -> r 2 )[/t/a] := ri[ w/a] -» r 2 [«/a] 
(Tr)[/t/a] := 'Tt[k/q] 
a, [it/a] := Ki 



Figure 5. Promotion of datatypes in GHC: t[k/o\ (adapted from 
Figure 9 of Yorgey et al. (2012)) 

When reducing the body of the let (cons (cons xs)), the type vari- 
ables ft are x and xs. This is how these variables are passed into 
LetConsSym2. The substitution 0 is cons-f; H» LetConsSym2 x xs. 
Thus, when the reduction algorithm sees consi[, it knows what to 
replace it with. 

We can consider the top-level to be one big let expression. Ac- 
cordingly, there is always a substitution 6 during reduction; outside 
of any local let, it is essentially the "make uppercase identifier" 
function. These substitutions are built by reducing the list of type- 
level let-declarations, as shown in Figure 4. 

The figure also contains definitions of the lifting operations 
which are used in producing top-level declarations to imple- 
ment the extra features present in extended types. Other than the 
clutter of dealing with lots of syntax, there is nothing terribly unex- 
pected here. 

6.4 Type-correctness 

We define typing judgements for expressions, Y h e : r, and 
types, F h r : k, based on how users expect Haskell to work. 
We are unaware of a simple formulation of surface Haskell's type 
system and so have written this ourselves. There is other work in 
this area (Faxen 2002; Jones 1999), but the nature of the existing 
formulations makes them hard to adapt for our purposes. Note that 
the typing judgements presented here are different than that in work 
on GHC's core language FC (for example, Sulzmann et al. (2007)), 
because we are working solely in surface Haskell. The typing rules 
appear in the extended version of this paper. They have been left 
out of the paper proper due to space concerns, but there is nothing 
unexpected. 

Promotion We prove type safety by proving the safety of pro- 
motion ft-, with respect to typing judgements for extended types 
Y hi x t f : k, also in the extended version of this paper. These rules 
combine the normal typing rules with new rules for the extra type- 
level forms that closely resemble their term-level equivalents. 
We first prove that defunctionalization symbols work as desired: 

Lemma (Data constructor symbols). If K : a and if aft exists, 
then Sym 0 (K) : crft. 

The proof of this lemma depends on the relationship between 
our promotion algorithm and GHC's internal promotion algorithm. 
GHC's version, in Figure 5, is written as a substitution of kinds in 
for the type variables in a type, as every free type variable must 
become a kind during GHC's promotion. 

We use this fact to prove the following: 

Lemma (Promotion to extended types is well-typed). Let rft, eft, 
and rft exist. IfY h e : t, then rft h ext eft : rft. 

Reduction Having shown that promotion to extended types 
works, we must now prove that reduction also is well typed. How- 
ever, reduction depends more critically on the contexts where it 
is performed. Thus, we introduce the idea of top-level contexts, 
which simplifies the statements of the lemmas: 

Definition (Top-level contexts and substitutions). Let 8 be a set of 

— — 0 

declarations such that 0 h S Yo and do = [<5ftJ 0 . Then, Yo is 

a top-level context, and 8q is the associated top-level substitution. 
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This definition uses the judgement 0 h S ~* To, which says 
that the declarations 8 are well-typed in an empty context and 
induce a typing context To when the declarations are in scope. 
The intent is that 8 are top-level declarations. The do mentioned 
works out in practice to be the "make uppercase identifier" function 
described above. 

Lemma (Type reduction preserves kinds). Let To be a top-level 
context and 8 o Its associated substitution. //Toft \~ext T '■ K » then 
[Toff J \~ \j\ 0° : n and the emitted type declarations are valid. 

Full type-correctness Putting these together yields the following: 

Theorem (Promotion is well-typed). Let To and 9 0 be a top-level 
context and Its associated substitution. If To h e : r, where eff and 
rff exist, then 0 h [eff J 0 ° : rff. 

6.5 Semantics 

We have shown that promoting a well-typed expression yields a 
well-kinded type. We must also show that this well-kinded type 
behaves the same as the original expression. To do so, we define a 
small-step operational semantics both for expressions and for types. 
We are unfamiliar with previous work on developing an operational 
semantics for Haskell. The expression semantics relation, E; e — > 
E'; e', is based on an understanding of how Haskell expressions 
reduce." The step relation tracks an environment E, which is 
just a set of let-bound variables for use in lookup. The type-level 
semantics, r — > r', is a congruence over type family reduction, 
as type family reduction is the only way that a type "steps." 

Conjecture (Promotion preserves semantics for closed terms). Let 
To be a top-level context and 6o its associated substitution, where 
Eo = So are the top-level declarations. If To h e : r, Eo; e — >* 
E'; e', both eff and rff exist, and e' consists only of data construc- 
tors and applications, then e' 'ff exists and LefrJ^ 0 — >* L e 'lVJ 

The intuition behind the above conjecture is that an expression 
well-typed in a top-level context that eventually reduces to an 
observable value (that is, applied data constructors) promotes to a 
type that reduces to the promoted form of the value. 

Alas, we are unable to prove this conjecture in full because of 
reduction's dependence on lambda lifting. Proving lambda lifting 
correct is a large enterprise of itself, and is beyond the scope 
of this paper. We refer the reader to the work of Fischbach and 
Hannan (2003), which states a lambda lifting algorithm and proves 
it correct, at length. 

Instead of proving the conjecture above, we settle for proving 
that an extension of the type-level semantics, uJ; f — > ext u'; 
supporting extended types, agrees with our term-level semantics: 

Theorem (Promotion to extended types preserves semantics). // 

E; e — > E'; e' and if eff exists, then Eff; eff — > ext E'ff; e'ff. 

Note that E is just a collection of let-declarations S, and can be 
promoted by the relevant algorithm in Figure 3. 

7. Discussion 

7.1 Type inference 

In Section 4.3, we claim that an unsaturated type family interferes 
with type inference. The problem stems from the fact that GHC 
assumes both injectivity and generativity of type application. By 
injectivity, we mean that if GHC can derive (a b) ~ (a c), then 
it can conclude b ~ c. Generativity means that if GHC can derive 
(a b) ~ (c d), then it can conclude a ~ c. In other words, 



11 No attempt is made at modeling Haskell's call-by-need semantics; we 
settle for call-by-name. 



a generative type application creates something new, unequal to 
anything created with other types. 

Type family application is neither injective nor generative. 
Thus, GHC must ensure that an unapplied type family can never be 
abstracted over - that is, no type variable can ever be instantiated 
to a partially-applied type family. If we did perform such an instan- 
tiation, GHC's injectivity and generativity assumptions would be 
invalid, and type inference may arrive at a wrong conclusion. 

In this paper, we show a way essentially to manipulate partially- 
applied type functions. How does this fit with the story above? 
Critically, the application of a type function in this paper is done 
explicitly, with the @@ operator. Thus, a programmer can use un- 
saturated type functions by explicitly choosing what assumptions 
hold at each type application. When we say a b (normal type ap- 
plication), that application is injective and generative, as usual. If, 
however, we say a @@ b, then the application is not necessarily ei- 
ther injective or generative. 

This dichotomy works well with GHC's treatment of type fam- 
ily arguments. Recall that @@ is implemented as an ordinary open 
type family. Thus, GHC will not break it apart or use the injec- 
tivity and generativity assumptions on applications built with @@. 
Happily, this is exactly the behaviour that we want. 

The fact that we introduce a new arrow -» fits nicely with this, 
as well. The regular arrow — >, when classifying types, indicates an 
injective, generative function. Our new arrow -» denotes a function 
without these assumptions. When — > is used to classify terms, we 
make no assumptions about the functions involved. It is thus natural 
to promote the type — > to the kind -», not to the kind — K 

7.2 Eliminating symbols 

We can go further and argue that GHC's current choice to use juxta- 
position for type family application is a design error. The identical 
appearance of normal application and type family application hides 
the fact that these are treated differently by GHC. For example, con- 
sider these type signatures: 

exi :: Maybe a — > Bool 
ex2 :: Foogle a — > Bool 

We know that exi 's type is unambiguous - that is, we can infer 
the type a if we know Maybe a. But, what about ex2? To know 
whether the type is ambiguous, we must know how Foogle is 
defined. Is it a type family, or a type constructor? The answer to that 
question directly informs ex2's level of ambiguity. A library author 
might want to change the nature of Foogle from a type constructor 
to a type family; now, that change impacts users. 

On the other hand, if all type families had to be applied explic- 
itly in user code, the difference would be manifest: 

ex 2 :: Foogle @@ a — > Bool 

Now, programmers can easily see that ex2's type is ambiguous and 
ponder how to fix it. 

In the bold new world where type family application is explicit, 
the appearance of a type family in a program would mean essen- 
tially what we mean by a 0-symbol. We can also imagine that GHC 
could allow @@ to be used with proper type constructors, as — > could 
be considered a sub-type of -». 

7.3 Semantic differences between terms and types 

Terms are evaluated on a by-need basis. How does this translate 
to types? Type evaluation is non-deterministic and operates differ- 
ently than term-level evaluation. Indeed, type-level "evaluation" is 
implemented within GHC by constraint solving: GHC translates a 
type such as Vec a (Pred n) to (Pred n ~ m) => Vec a m for a 
fresh m. See Vytiniotis et al. (201 1) for details. 
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Despite this significant difference, we have yet to see any prob- 
lems play out in our work (neglecting the impossibility of infinite 
types). It is possible to define type families with non-linear equa- 
tions (i.e., left-hand sides with a repeated variable) and to define 
type families over the kind *. Both of these have semantics dif- 
ferent than anything seen at the term level. For example, note the 
somewhat unintuitive rules for simplifying closed type families de- 
scribed by Eisenberg et al. (2014). However, it seems that by re- 
stricting the form of type families to look like promoted term-level 
functions, we sidestep these problems nicely. 

7.4 Features beyond Haskell 2010 

We have restricted the scope of our work to include only features 
mentioned in Chapters 3 and 4 of the Haskell 2010 Report. How- 
ever, we ourselves enjoy using the many features that GHC sup- 
ports which fall outside this subset. Many of these features are not 
possible to promote. Without first-class kind polymorphism (such 
as higher-rank kinds), we cannot promote higher-rank types. With- 
out kind-level equality, we cannot promote equality constraints, 
GADTs, or type families; see Weirich et al. (2013) for some the- 
oretical work toward lifting this restriction. Overlapping and inco- 
herent class instances would lead to overlapping open type family 
equations; these are surely not promotable. Intriguingly, GHC does 
allow functional dependencies among kind variables, so these pro- 
mote without a problem. We leave it open to future study to deter- 
mine which other extensions of GHC are promotable. 

7.5 Future work 

The most tempting direction of future work is to implement a pro- 
motion algorithm in GHC directly. With support for partial appli- 
cation in types along the lines of what we propose in Section 7.2, 
this could be done with much less clutter than we see in this pa- 
per. A non- trivial problem in this work is that of namespaces: how 
can we remain backward compatible while allowing some terms to 
be used in types? Dealing with naming issues was a recurrent and 
annoying problem in our work. An important advantage of direct 
implementation within GHC is that the algorithm would work in 
a fully typed setting. Instead of generating unusable definitions - 
as demonstrated in Section 5 - the algorithm could detect errors 
and report them to the programmer. It would also be possible to 
correctly promote functions stored inside datatypes. 

We would also want a more complete treatment of promoted 
literals within GHC. The current mismatch between term-level in- 
tegers and type-level Nats is inconvenient and can prevent promo- 
tion of term-level functions to the type level. Similarly, the kind 
Symbol and the type String behave too differently to make pro- 
motion of String functions possible. 

With these improvements in place, we would be even closer 
to enabling dependently typed programming in Haskell, along the 
lines of the work by Gundry (2013). That work takes care in 
identifying a subset of Haskell that can be shared between the term 
level and type level. This subset notably leaves out anonymous and 
partially-applied functions. The work done here shows that these 
forms, too, can be included in types and will enable an even more 
expressive dependently typed Haskell. 
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